1. Field of the Invention
This invention relates to automated testing of integrated-circuit (IC) components. More specifically, it relates to system-wide testing of powered-up electronic systems encompassing a multiplicity of IC-containing modules (e.g., printed circuit boards). More specifically yet, it relates to apparatus and protocol for a multi-drop application of IEEE Std 1149.1 to each board coupled in parallel to a system-level controller through a master test bus. It thereby extends the IEEE Std 1149.1 test protocol to the system level; furthermore, it permits the testing of inter-board connects as well as intra-board connects in a way that utilizes essentially all of the hardware and software elements previously developed for testing individual, isolated boards within IEEE Std 1149.1--such as the required micro-code. Finally, by providing a board-level ring controller, the present invention makes more flexible the testing of boards bearing more than a single IEEE Std 1149.1 ring of devices, while allowing a reduction in the number of edge connector pins for multi-ring boards.
2. Description of Prior Art
Introduction
From the earliest days of solid-state electronics, individual circuit components have been tested prior to incorporation into circuits, and completed circuits have been monitored for proper performance and operating characteristics. In the beginning, those individual components consisted of single transistors, rectifiers, and the like. It was simple to set up the appropriate test jigs for examining the isolated device and it was likewise simple in the completed circuit to gain access to the pins needed for in situ testing of the device--which could easily be replaced if it failed.
As the complexity of solid-state electronic circuits has grown, so too has testing complexity, along with the importance of maintaining testability. At the lowest level, this means ensuring the testability of individual devices (which are now integrated-circuit chips--ICs) before they are incorporated into more extended circuits, typically through being mounted on printed circuit boards. The testing of the individual chip does not differ qualitatively from that of the individual transistor in earlier times. In both cases, all of the pins used for connecting the device to the outside world are readily accessible for the application of test voltages and the sensing of device responses. In both cases, the goal is to detect unwanted "shorts" and "opens" and to determine whether the device "logic" is correct. Until recently, a similar carry-over of the testing technique was possible and practicable for the completed circuit, the board loaded with interconnected ICs. Using a "bed of nails" jig or its equivalent, the test circuit could be electrically connected to every node--i.e., to every point where the pin of one IC connected to the pin of another or to the outside world--in the circuit under test. This provided direct means for checking the completed circuit module--the loaded board--for shorted and open leads and for proper logic, prior to the module being inserted into an extended, multi-board system. (Typically a board is made part of a larger system by being inserted into a slot in a system backplane, the physical framework used for holding the various system constituents in proximity.)
The "bed of nails" approach has never been practicable for testing either an extended system or even an individual module once that module is included in an extended system. Moreover, the increasing device density on loaded boards (as well as the increasing number of pins per device) has made the "bed of nails" increasingly impracticable even for testing a single, isolated module. The final blow to this testing approach is being dealt by the introduction and rapid expansion of surface-mounted technology (SMT) for loading and interconnecting ICs on boards. SMT involves the replacement of IC pins by pedestals designed to be butted against contact pads on the circuit board. It generally leads to circuit nodes being inaccessible from the side of the board opposite the ICs. Furthermore, because all of the connections for devices are located on the same side as the devices themselves, SMT makes possible a double loading of boards, with devices being affixed on both sides, utilizing circuit nodes which are essentially concealed from outside access or view. Although probe points can be designed into any board--i.e., added specifically for testing purposes--this is very expensive and highly impracticable in essentially all cases. Thus, the SMT advance, made necessary by the continuing increase in logic density, promises to make "bed of nails" testing completely obsolete.
Electrical connections still accessible on an SMT-loaded circuit board are the electrical contacts by which the board is to be connected to the outside world; this generally means the contacts by which the board is to be connected to an extended system via backplane-slot terminals: its edge connectors. The use of these contacts to test the individual board, either immediately post-production or immediately prior to its insertion into an extended system, requires a level of interaction between test engineers and circuit-design engineers far beyond that previously necessary. There now has to be circuitry--a board test bus--coupling the edge connectors to key points within the circuit module; in general there may also need to be test-enabling architecture added to the chips. A brute-force approach would be to connect slot edge connector pins to test buses running to every node in the circuit module--maintaining, in effect, the testing simplicity of the "bed of nails" approach, and obviating the need of test architecture on the chip--but at the cost of a myriad of test leads and concomitant capacitive coupling. This is obviously not an acceptable solution for high-speed circuits operating in spacelimited (and pin-limited) environments.
The most widely-used approach to modern testing of high-density circuits uses the boundary-scan technique. Boundary-scan testing reduces to a minimum the number of test leads to be added to the board and the number of edge connector contacts needed for test purposes; it demands, however, a great deal more ingenuity and analysis on the part of the test engineer. It also demands cooperation not just from those designing and assembling circuit modules from individual ICs but also from those designing and manufacturing the ICs themselves. The "boundary" of boundary-scan testing is the IC boundary, the totality of input and output pins on the chip. To make possible the testing, certain logic circuitry (a "Boundary-Scan Cell") is interposed on each pin in such a way that this Boundary-Scan Cell separates the pin's external wire from its on-chip logic connection. Boundary-Scan Cells provide the means for mediating the testing and also for ensuring that the presence of the test connections does not compromise normal IC performance. To enable the testing of a circuit module, the individual ICs are daisy-chained together into a test ring, with a test lead connected in series to the Boundary-Scan Cell of every pin. (See FIG. 1, which shows that the total physical chip contains both the Boundary-Scan Cell architecture and the on-chip logic, with the external pins available for interconnection to other chips, just as before. The various control lines necessary to implement Boundary-Scan Cell testing are not shown in FIG. 1.)
Boundary-Scan Cells are designed so that collectively they provide a shift register into which a test stimulus--a pattern of logic-high and logic-low voltages--can be forced. Specifically, through the test input and the series connection of Boundary-Scan Cells, a binary number constituting the test stimulus can be shifted into this register, one bit per cell, under the intercession of control lines not shown in FIG. 1. Once shifted in, the test stimulus can be applied to the chip logic and the resulting output from the logic captured by the Boundary-Scan Cell shift register and stored. The test output is subsequently shifted out of the shift register as a binary number to be analyzed by the test controller for information concerning on-chip logic performance and pin integrity (and, for those rings containing more than one chip, interconnections).
The realization early on that Boundary-Scan testing circuitry could be structured in many different ways, and that many different test protocols--some well-suited to one module design but not to another--were bound to arise in an uncoordinated field, led to the development of an industry-wide Boundary-Scan testing standard. Through the Joint European Test Action Group (JETAG)--and the Joint Test Action Group (JTAG) to which it evolved--a standard has been established that should result in test-architecture and testprotocol uniformity throughout the industry. This standard is IEEE Std 1149.1 ("the standard"), ratified by the IEEE in February, 1990, and adopted by ANSI in August, 1990. Circuit boards loaded with standard-compliant devices connected together into test rings by standard-compliant local test buses accessible at the edge connectors ("standard-compliant boards" or "standard-compliant modules") constitute known entities for down-stream manufacturers and their test engineers, which means that module-testing schemes for the boards in question can be more efficiently planned and implemented.
JTAG-IEEE Std 1149.1 for Testing Individual Modules
IEEE Std 1149.1--also referred to as "JTAG"--specifies testability standards for a circuit module made up of a number of interconnected ICs ("chips") mounted on a circuit board or its equivalent. While not defining every detail of standard-compliant circuits, IEEE Std 1149.1 does specify minimum requirements to be met by every standard-compliant board and every standard-compliant chip.
IEEE Std 1149.1 is based in the individual chip, each of which must contain a Test Access Port (TAP), a TAP controller, an Instruction Register, and at least two Data Registers--one being the Boundary-Scan Register residing in the Boundary-Scan Cells, and the other a Bypass Register. Each chip's TAP must contain at a minimum three specific input pins--TCK (Test Clock), TMS (Test Mode Selector), and TDI (Test Data Input)--and one specific output pin--TDO (Test Data Output). An optional fifth TAP pin is for a Test Reset (TRST) line. Since there was no collective name assigned to this test architecture, common usage often refers the entire collection of test architecture on the chip "the TAP." Strictly speaking, "TAP" refers only to the collection of four or five test pins on the standard-compliant chip.
Corresponding to the four or five TAP pins associated with the individual chips, an external test bus joining a test control unit to the board has four or five leads: TCK, TMS, TDI, TDO, (TRST). On the standard-compliant board--thought of as holding a first chip, a second chip, etc., through an nth chip, the last chip--the external TDI lead is coupled directly to the TDI pin of the first chip's TAP. On the first chip and on each chip, the TDI pin is connected in series through all of the Boundary-Scan Cells, returning to the TDO pin of the TAP. The TDO pin of the first chip's TAP is then connected directly to the TDI pin of the second chip; the TDO pin of the second chip is connected directly to the TDI pin of the third chip; and so forth. The TDO pin of the last chip goes to the external test bus' TDO line. In contrast, the TCK and TMS leads of the external test bus are connected in parallel to the corresponding TAP pins of all of the individual chips. See FIG. 2. (It is noted that, although each standard-compliant board has been presented as just having a single ring of daisy-chained chips, the standard also provides for a board holding a number of such rings. Within IEEE Std. 1149.1, each ring is independent of the others. The presence of multiple test rings on a board simply means that there are several separate board test buses, with a corresponding increase in the number of edge connector pins dedicated to testing.)
The mechanics of the testing depend on the fact that each Boundary-Scan Cell is capable of transferring data (a) between its on-chip logic side and the pin by which the chip is connected to the rest of the system, (b) from its on-chip logic side to the next Cell, (c) from the previous Cell to itself, (d) from the previous Cell to the next Cell (where the "next Cell" is further from the TDI connect and closer to the TDO connect, and the "previous Cell" is in the opposite direction). Which of these transfers a particular Cell performs is determined by the control signals applied to that Cell from other parts of the test architecture, in particular from the TAP Controller, as described below. In response to the proper control inputs, the Cells will isolate the test circuitry from the operation of the chip and will itself become "transparent" to the ordinary operation of the chip as a unit in the extended system. Provided with different control inputs, the Cells will participate in chip-interconnect tests or in testing of the chip logic.
In general, the binary number constituting the test stimulus will have one bit for each of the pins from all the chips in the test Ring (with the least significant bit--LSB--residing in the Cell closest to the TDO line after the shifting in is completed). (It may be that some, or most, of the chips are not of interest to the testing. For such a chip the test stimulus--and resultant response--will be shifted not through that chip's entire Boundary-Scan Register but rather just through a one-bit Bypass Register specified by IEEE Std 1149.1. The length of the numbers shifted in and out will be reduced accordingly.) The shifting in of the test stimulus from the external test bus line TDI and the shifting out of the test data onto the external test bus line TDO are clocked by the TCK signal and mediated by control signals sent the Boundary-Scan Cells by the TAP Controller, which also regulates flow into the Instruction Register and is in turn controlled by TMS and TCK. The TCK signal is a uniform pulse train serving to synchronize the various test events, which are triggered either by the rising edge or the falling edge of the first TCK pulse to arrive at the relevant controller or register subsequent to certain conditions precedent being met. The TMS signal forms the heart of a particular testing protocol and is shaped by the test controller to be a series of logic-high and logic-low levels of irregular duration. These levels drive the testing, in particular by driving the TAP Controller, as described below. TMS level changes are generally made to occur on the falling edge of a TCK pulse so as to be as far as possible from a rising edge, the trigger for most test events.
The standard-compliant TAP Controller is a sixteen-state finite state machine ("machine") which at any instant will be in a state determined by its initial state and the subsequent sequence of TMS signals received. The state that the TAP Controller is in determines the control signals it sends to the rest of the test architecture, in particular to the Boundary-Scan Cells. Part of the IEEE Std 1149.1 definition of the TAP Controller is, therefore, a definition of what the control signal outputs to other parts of the test architecture are to achieve for each TAP Controller state.
FIG. 3 shows the TAP Controller state diagram along with the protocol for state changes. State events are triggered by each rising edge of TCK and are determined by the TMS logic level at that instant. The arrows and associated 0's and 1's at each of the sixteen states indicate what the TAP Controller will do upon receiving a TCK rising edge, depending upon whether TMS is logic-low or logic-high, respectively. For example, if the TAP Controller is in the Select-IR-Scan state, it will--on the next TCK rising edge--go to the Test-Logic-Reset state if, and only if, TMS is logic-high at that time. If TMS is logic-low, the TAP Controller will change to the Capture-IR state. For another example, note from FIG. 3 that if the TAP Controller is in the Shift-IR state, it will remain in that state as long as TMS remains low.
IEEE Std 1149.1 requires that the TMS and TDI inputs to the chip test architecture be logic-high should they not be driven by an external signal (i.e., that the TMS and TDI inputs be stuck-at-high if, for example, the corresponding lines in the external test bus be open). It can be seen from FIG. 3, that a stuck-at-high TMS will drive the TAP Controllers back to the Test-Logic-Reset state--the state which de-couples the chip logic from the test circuitry--regardless of where they start (providing that TCK continues to function). For example, if the starting state is Exit1-IR, each TAP Controller will be driven in four TCK ticks back to the Exit1-IR state: Exit1-IR.fwdarw.Update-IR.fwdarw.Sel-DR-Scan.fwdarw.Sel-IR-Scan.fwdarw.Tes t-Logic-Reset. And so forth. Since the board test bus is de-coupled from the IC logic circuitry when the TAP Controller is in the Test-Logic-Reset state, this ensures that if the external test bus is disconnected, or if no active testing is being conducted even though the external test bus is connected, the system will be able to operate without being compromised by the presence of the test circuitry.
The effect of TDI stuck at high is to limit the instructions and signals shifted in to all ones. An all-ones signal is given special significance in IEEE Std 1149.1; read as an instruction, it is the BYPASS instruction. Consequently, the effect of an open TDI line, all else working, is to decouple the test bus from the on-chip logic.
Finally, the standard requires that if a TRST pin is provided at the TAP, and a corresponding line in the board test bus, that this also must be stuck-at-high in the absence of an incoming signal.
An implementation of the IEEE Std 1149.1 requirement regarding the stuck-at-high provision for TMS and TDI is depicted in FIG. 4, which shows a block diagram of the test circuitry on a standard-compliant board loaded with two standard-compliant chips; TMS and TDI are both linked to V.sub.CC --the high-potential power rail for all the circuitry--by pull-up resistors A board test bus containing the four leads--TDI, TDO, TCK, TMS--is shown.
In addition to the provision for sending the TAP Controller to the Test-Logic-Reset state whenever TMS is left open or set at logic-high, IEEE Std 1149.1 requires that upon power-up the TAP Controller must be put automatically into the Test-Logic-Reset state. (This requirement is changed somewhat for those standard-compliant boards having the optional fifth lead in the TAP, TRST, with which the TAP Controllers can be put in the Test-Logic-Reset at any time, asynchronously.)
As shown in FIG. 4, each TAP Controller is multiply connected to its Instruction Register (which includes a shift register and a parallel output/latch register and associated Instruction Decoder), to its Data Registers, and to other components of the test circuitry on each chip. It is through these connections, and the control exercised over the TAP Controllers by TMS, that the external test controller determines into which register the incoming TDI signal--which will contain instructions as well as test stimulus information--is to be shifted at each step in the testing sequence. Through this means, the test input of the entire interconnected collection of chips on a board is coordinated; the TDI signal is shifted into the Boundary-Scan Register and the test data which enters the Boundary-Scan Register as the result of the voltage levels imposed on the pins later shifted out to the TDO line as a serial output to the external test bus for interpretation. (For on-chip-logic testing, one may think roughly of the TDI signal imposing a sequence of logic levels on the chip's input pins and the test data then appearing at the output pins, to be shifted onto TDO for analysis.)
The operation of the Boundary-Scan Test procedure of IEEE Std 1149.1 can be understood in more detail by continuing reference to FIGS. 1 through 4 and a review of the requirements of IEEE Std 1149.1 for the control outputs of the TAP Controller in its various states. Prior to the start of a board-testing sequence, all the TAP Controllers will be in the Test-Logic-Reset state, which is required to cause the test bus to be disconnected from the on-chip logic and from the pin interconnections. With the TAP Controllers in this state, all of the Boundary-Scan Cells will be transparent to operational signals (as opposed to test signals) flowing into and out of each chip. The initial signals on the external test bus will be the TCK pulse train--assumed to be present throughout all of the following discussion--and a logic-high TMS, to temporarily hold the TAP Controllers in the Test-Logic-Reset state, followed by a logic-low TMS to put the TAP Controllers into the Run-Test/Idle state, which resembles a staging position. With the TAP Controllers in Run-Test/Idle, the test circuit is still decoupled for the chips, but the TAP Controllers are set to receive either an Instruction-Register-Scan Sequence (IR-Scan)--which will shift in and assert an instruction--or a Data-Register-Scan Sequence (DR-Scan)--which will shift in and assert a test sequence in accord with the whatever instruction is then in effect. A test will normally commence with an IR-Scan. The Instruction Register is a compound device. It consists in part of a shift register (IR Shift Register) which can shift numbers in from TDI and out to TDO whenever it is in the TDI/TDO scan path, i.e., when its first stage has TDI as input and its last stage has TDO as output. That IR Shift Register is connected in parallel to a Parallel Output Register which serves to latch the number it receives from the IR Shift Register and present it for implementation to the IR Decoder, to which it is also connected in parallel. It is the IR Decoder which implements the instruction by sending control signals to various components of the test architecture, control signals which will determine the operating modes of the respective components. The IR Decoder will, for example, cause the Boundary-Scan Register to be placed into the TDI/TDO path when the requisite instruction has been scanned in and latched in the IR Parallel Output Register. (The instruction in the IR Parallel Output Register at any time is the "current instruction.") Also exercising control over the various components of the test architecture is the TAP Controller itself, as an explicit function of the state it is in.
Following is a list of the steps involved in an IR-Scan. The TMS values required by these steps can be inferred from FIG. 3. Recall that each TAP Controller and directly-associated circuitry controls the Boundary-Scan Cells on a single chip out of the several in the test Ring; TMS is connected in parallel to all of the TAP Controllers in the Ring and thus synchronizes what is happening on the various chips.
IR-Scan
(a) Each TAP Controller is placed in the Select-IR-Scan state, which results in it placing its associated IR Shift Register into the TDI/TDO scan path; PA1 (b) Each TAP Controller is next placed in the Capture-IR state, which causes the parallel transfer of the binary number "01" into the two least significant positions of the IR Shift Register. (This step is tied in with subsequently providing "reassurance" to the test controller that the test architecture on each chip is functioning properly.) PA1 (c) Each TAP Controller is then placed in the Shift-IR state and left there for the number of TCK ticks necessary to shift into the Ring of IR Shift Registers the entire binary instruction concurrently being sent on TDI. (Note that this also will shift out to TDO--on the first two TCK pulses--the "01" stored in the LSB locations of each of the individual IR Shift Registers in the Ring.) PA1 (d) Once the instruction has been shifted in, the TAP Controllers are moved to the Update-IR state which effects a parallel transfer of the number then in the IR Shift Registers to the IR Parallel Output Registers on the next falling edge of TCK. (Under IEEE Std 1149.1, all data coming into the chip--TDI, TMS chip inputs--are clocked in on the rising edge of TCK. All actions affecting the outputs are implemented on the falling edge. "Updating" a new instruction can have the effect of changing the chip outputs; therefore the IR Parallel Output Register is clocked on the falling edge.) This transfer, which is the last stage of the IR-Scan, will latch in a new "current instruction." "Updating" an instruction involves this transfer and consequent implementation of the instruction. The instruction is implemented by the IR Decoder which is connected in parallel to the IR Parallel Output Register and which then transmits control output signals which are commensurate with the current instruction. PA1 (e) After being in the Update-IR for one tick on TCK, the TAP Controllers on all of the chips on the board under test will be sent to either Run-Test/Idle or to Select-DR-Scan, ending the IR-Scan. PA1 (1) Backplane interconnect testing cannot be performed, since the backplane drivers of two modules cannot be controlled simultaneously; PA1 (2) The Backplane Test Bus Link cannot be used to start autonomous test functions--such as a Built-In Self Test (BIST)--and then proceed to perform other test functions on other modules or local rings; PA1 (3) Any action where two or more boards must be enabled is virtually impossible--for example, the scheme cannot be used to perform a system-wide SAMPLE operation.
It may be that there is provision on the chip for a Built-In Self-Test (BIST) that is independent of--or, better stated, parallel to--IEEE Std 1149.1 protocol. In that case, the first instruction shifted in and updated may be the standard-prescribed RUNBIST instruction, with the IR-Scan ending with the TAP Controllers in the Run-Test/Idle state, where they would be left while the BIST ran.
There is in IEEE Std 1149.1 provision for a chip identification scheme, wherein each chip will have a hardwired 32-bit Device ID Register. By causing the Device ID Register number to be switched out onto TDO, the test controller can interrogate the board so as to the devices (chips) present and then store complete information regarding devices on the board and the order in which they occur in the Test Ring. The instruction provided by the standard for the interrogation is IDCODE. When IDCODE becomes the current instruction, the Device Identification Register is placed in the TDI/TDO scan path.
Placing each TAP Controller back in its Test-Logic-Reset state causes the test circuitry to be disconnected from the chip logic circuitry. It also means that the control logic and Instruction Registers get reset, preventing further interconnect testing with that Test Ring.
System-Wide Testing
IEEE Std 1149.1 establishes an industry standard for Boundary-Scan testing of circuit modules, ensuring that manufacturers downstream from chip producers can load chips on a board in the knowledge that the completed board can be tested in a particular manner. Similarly, systems manufacturers downstream from suppliers of loaded standard-compliant boards can establish their own pre-assembly board tests with the knowledge that the anticipated board test bus will be present and interconnected to specific test circuitry on each chip.
Unfortunately, IEEE Std 1149.1 by itself does not provide for, or otherwise address, system-wide testing of an assembled multi-board system. Although a straightforward extension of the standard to system-wide testing can be imagined--that where a separate test bus is run from a central test controller to each board in the system (with appropriate multiplexing to keep the data exchange with each board coherent and separable)--the drawbacks of such a one-test-bus-per-board (actually one-test-bus-per-test-Ring) approach are equally obvious. They include such obstacles as excess cabling, repetitive hardware, and extremely complex data collection and analysis. Much the same may be said for an approach which daisy-chains together all of the boards--and all of the chips--in the system into one immense test Ring. The proliferation of test buses is avoided, but the complexity of the testing becomes truly overwhelming. Indeed, just the determination of the degree of testing completeness achieved by a particular test sequence is an imposing task. Finally, it seems likely that daisy-chain testing at the system-wide level would result in test hardware becoming quite dependent on the specific details of the system under test, a return to the circuit-dependent test set-ups which IEEE Std 1149.1 is intended to discourage.
Apart from the fundamental problems implicit in daisy-chaining all of the chips together into one immense Ring, there is the mundane but nevertheless serious impediment that arises from the fact that it is not really the boards that are being daisy-chained but rather the backplane slots that are to receive the boards as the system is assembled. This daisy-chaining of slots requires for its integrity that every slot wired into the chain be occupied; a vacant slot (e.g., an "expansion slot" in a Personal Computer) will disrupt the serially-connected test circuit.
The empty-slot problem is easy to overcome once the daisy-chaining of boards is abandoned in favor of a multi-drop arrangement, where the slots are connected in parallel to a single system test bus. One multi-drop scheme for system-wide testing system is incorporated in the developing IEEE P1149.5: "Standard Backplane Module Test and Maintenance (MTM) Bus Protocol." The architecturally-defined test and maintenance bus specified by IEEE P1149.5 would provide a link between a backplane test controller and individual test access ports associated with individual boards. The direction in which work on the evolving IEEE P1149.5 is proceeding appears to call for relatively complex backplane protocols which, while possibly justified in certain large-system contexts, appear to be impractical for small to medium-sized systems. Implementing such a standard will require hardware development and installation costs as well as significant software-creation expenditures.
A multi-drop scheme making use of and building on already-completed IEEE Std 1149.1 implementation work appears to have many advantages over any alternative approach, including that of IEEE P1149.5. Indeed, this philosophy has applicability to any module-based Boundary-Scan test scheme now in use or subsequently devised; the extension of such a scheme to test an extended system appears to be best done by building on the test architecture and protocol devised for the module level, extending it hierarchically in a manner discussed here specifically for the extension of IEEE Std 1149.1 to the system level.
Generalized Extension of IEEE Std 1149.1
The expansion of IEEE Std 1149.1 to a hierarchical multi-drop, system-wide scheme can be understood by reference to FIG. 5 and the following discussion, in which the test controller is now designated the Test Master and the system test bus the Backplane Test Bus.
FIG. 5 schematically depicts a backplane with n+1 slots, all of which are connected in parallel to a Backplane Test Bus conveying the four required IEEE Std 1149.1 leads (the optional TRST is not included in the figure)--and at least one of which is empty and one of which is occupied by a board bearing the Test Master. Two boards representative of those making up the system are shown in some detail. The entity labelled Backplane Test Bus Link on each of the representative boards is the collection of circuits serving to interface the Backplane Test Bus with the Local Bus containing the Test Ring of individual chips. The Backplane Test Bus Link is a standard-compliant IC (just as are the chips to be tested). As such, the Backplane Test Bus Link has a TAP, which is where the Backplane Test Bus couples in. Since all Backplane Test Bus Links will be connected in a similar fashion, the Test Master is able to broadcast test signals and instructions to those Links over the Backplane Test Bus. Each Backplane Test Bus Link contains, in addition to the entities required by IEEE Std 1149.1, the circuitry necessary to enable it to be selected for testing by the Test Master. It will also have to have the control means to synchronize the TAP Controllers on the individual chips to its own TAP Controller. FIG. 6a presents this schematically, with the Test Ring shown in some detail on one of the boards depicted.
The best way to utilize the standardization of the test architecture at the two levels (Backplane Test Bus Link and individual chip) appears to be to configure the test loop of the selected slot and Ring to include in the daisychain of TAPs that of the Backplane Test Bus Link itself, i.e., to put the Backplane Test Bus Link TAP on the Local Bus. This is what accounts for FIG. 5 showing TDO.sub.-- lc to lead from the Backplane Test Bus Link to the first chip's TAP while TDI.sub.-- lc leads to the Backplane Test Bus Link from the last chip's TAP. This is consistent with the usual IEEE Std 1149.1 terminology, where the TDO from one TAP goes into the TDI of the next TAP seriatim for a set of serially-connected/dasiy-chained TAPs.
Ideally, each Backplane Test Bus Link will also be able to coordinate all of the test Rings which may be on an individual board, thus eliminating the need for separate edge connector pins for each Ring and also introducing a degree of flexibility into the manner Rings may be combined for testing purposes.
The purpose of the Backplane Test Bus Link is to permit the Test Master--after a series of selection and interfacing instructions--to employ instructions and to exchange data with a particular IEEE Std 1149.1 test Ring as if the Test Master were a simple external test controller communicating with a single Ring on a single module. Furthermore, it is desired that the selection and interfacing instructions themselves be identical in form to Instruction and Data Scanning Sequences used under IEEE Std 1149.1. This is the reason for specifying that the Backplane Test Bus Link be a standard-compliant IC. It will contain a TAP Controller identical to the IEEE Std 1149.1 TAP Controller described earlier. In addition, it will contain circuitry permitting slot--and hence board--selection by the signals on the Backplane Test Bus, and Ring activation circuitry such that once the slot is selected all of the devices intermediary between the Test Master and the Local Ring become transparent.
FIG. 6 depicts in somewhat more detail the Backplane Test Bus Link which has been described above. It is seen to include a Backplane Test Bus Link Selection Controller tied to a source of information about the SLOT ID. (In this illustration, that information is shown as coming from a location off the board; it could also be positioned on the board.) Because of the parallel coupling of the individual Backplane Test Bus Links to the Backplane Test Bus, the Test Master broadcasts to all Backplane Test Bus Links at once. To initiate a test sequence, the Test Master needs to select a particular board. To do this it broadcasts an IR-Scan on TMS.sub.-- bp and then, on TDI.sub.-- bp, the ID number of the slot to be selected. If the two strings are equal, than that particular Backplane Test Bus Link is Selected; if not, it is disabled and its associated board isolated from the Backplane Test Bus. (The particular configuration shown in FIG. 6 is not meant to be limiting. Obviously, there are many ways to handle the addressing problem. The essential point is that there needs to be circuitry which can compare the address transmitted with the label on the particular slot or board and then enable the board in question to be coupled to the Backplane Test Bus for IEEE Std 1149.1 testing.)
After the selection process is completed, the Selected Backplane Test Bus Link, in response to signals from the Backplane Test Bus, then couples TDI.sub.-- bp and TDO.sub.-- bp, respectively, to TDO.sub.-- lc and TDI.sub.-- lc of the Board Test Bus for the circuit board in that slot. With continuing reference to FIG. 6, note the interposition between TDI.sub.-- lc and TDO.sub.-- bp of a tristate output buffer. This is essential since with multiple connections between TDI.sub.-- lc and TDO.sub.-- bp, the various TDI.sub.-- lc signals would otherwise be in contention. Only for the Selected slot will this tristate output buffer be enabled to transmit signals from the Test Ring during subsequent shift operations.
Potentially, a given board containing standard-compliant ICs may be organized into several test Rings. In such a case a separate Backplane Test Bus Link may be provided for each Ring or, preferably, a single Backplane Test Bus Link may form the interface for all of the Rings, with separate Local Buses with lines TDI.sub.-- Ic.O slashed., TDI.sub.-- Ic2, etc., TMS.sub.-- Ic.O slashed., TMS.sub.-- Ic1, TMS.sub.-- Ic2, etc., etc.
The only known prior-art implementation of the generalized IEEE Std 1149.1 scheme outlined above is described in An Architecture for Extending the IEEE Standard 1149.1 Test Access Port to System Backplanes, by Dilip Bhavsar, Proceedings of the 1991 International Test Conference, October, 1991 ("Bhavsar-91"). In discussing Bhavsar-91 the nomenclature defined above shall be used except where noted.
For the Backplane Test Bus Link Selection Controller, Bhavsar-91 utilizes the three-state machine defined by the state diagram of FIG. 7. It is designated as the BT-Link Control Logic and operates in conjunction with the Backplane Test Bus Link TAP Controller. This BT-Link Control Logic starts out in the Wait state upon the system being powered up, or if the Backplane Test Bus Link TAP Controller in the Test-Logic-Reset state (which will generally be the case upon power-up), or if the optional TRST line is present and an asynchronous reset signal has been sent. From that Wait state, the BT-Link Control Logic will go to the Selected state if the number shifted into the Backplane Test Bus Link IR is equal to the SLOT-ID (ADDR=SLOT-ID) and the Backplane Test Bus Link TAP Controller passes through its Update-IR state. The BT-Link Control Logic will be sent back to the Wait state if and only if the Backplane Test Bus Link TAP Controller is put in the Test-Logic-Reset state; the change will occur upon the next positive edge on TCK following the Backplane Test Bus Link TAP Controller going to that state. (It will also go to the Wait state for either of the other two conditions displayed in FIG. 7.)
Conversely, the BT-Link Control Logic will go to the UnSelected state from the Wait state if the number shifted into the Backplane Test Bus Link IR is not equal to the SLOT-ID (ADDR.noteq.SLOT-ID) and the Backplane Test Bus Link TAP Controller passes through the Update-lR state. It will remain UnSelected until the Backplane Test Bus Link TAP Controller is again placed in the Test-Logic-Reset state, when it will return to the Wait state.
The significance of the Wait state is that with the BT-Link Control Logic in that state, the associated Backplane Test Bus Link is waiting for an address. Any instruction transmitted on the TDI line of the Backplane Test Bus will be viewed as an address to be compared with the SLOT-ID as long at the BT-Link Control Logic is in the Wait state.
In addition to introducing a means to select a particular Backplane Test Bus Link for testing, Bhavsar-91 defines an instruction repertoire that enables control of the Local Chip TAP Controllers by the Backplane Test Bus Link TAP Controller (which in turn is under the control of the Test Master). Among these instructions, shifted into the Backplane Test Bus Link Instruction Register after the particular slot has been Selected, is ON.sub.-- LOCAL. This instruction causes the Backplane Test Bus Link to couple TMS.sub.-- bp to TMS.sub.-- lc. The Backplane Test Bus Link TAP Controller and the Local Chip TAP Controllers are synchronized by being placed in the Run-Test-Idle state immediately after the ON.sub.-- LOCAL instruction is updated. This places all of the TAP Controllers in the same state so that subsequently, with TMS.sub.-- bp received by the Backplane Test Bus Link TAP Controller being the same as TMS.sub.-- lc to the Local Chip TAP Controllers, those TAP Controllers remain synchronized, i.e., pass through the same sequence of states. I.e., after synchronization, the Backplane Test Bus Link TAP Controller and the Local Chip TAP Controllers are sequenced as one, and normal IEEE Std 1149.1 operations may commence. The inverse instruction of Bhavsar-91 is OFF.sub.-- LOCAL. When this instruction is updated, the Backplane Test Bus Link takes control of TMS.sub.-- lc, decoupling it from TMS.sub.-- bp and forcing it high. All the Local Chip TAP Controllers of the Local Ring which had been under test then return to the Test-Logic-Reset state and remain de-coupled from the Backplane Test Bus. This method of de-coupling the Backplane Test Bus from the Test Ring under test resets the controls on the Boundary-Scan Register of the Test Ring and thus makes inaccessible for any later testing the information which had been shifted into the Boundary-Scan Register while the Ring was on a Selected module. This de-selection process of Bhavsar-91--a step necessary before another slot can be selected for testing--seriously limits that prior-art test architecture when true system-wide testing is desired. The reset restriction means that:
Other disadvantages of Bhavsar-91 can be seen in its handling of Local TAP enabling and disabling. Although Bhavsar-91 mentions the possibility of having its Backplane Test Bus Link concurrently service several local ports (with a Test Ring of daisy-chained chips coupled to each) on a single selected board--it does not address the complications of configuring and synchronizing more than one local Test Ring simultaneously.
Therefore, what is needed is true system-wide test architecture able to make use of previously-implemented module-level test schemes. Ideally, such test architecture will make possible system-level testing which is in all qualitative respects identical to that used in the previously-implemented module-level tests underlying the enhancement. Also needed is a unified method of activating for such testing multiple Test Rings on a single board. In particular, what is needed is a means of configuring some or all of such Test Rings for testing as a unit. The present invention meets all of these needs and hence makes possible complete system-wide testing which builds on and can incorporate work already performed in implementing a module-level test scheme.